In a shared disk based file system, a plurality of computers share access to block storage devices that store file data. For example, network clients such as Microsoft Windows (Trademark) workstations may use the Common Internet File System (CIFS) protocol to access a shared disk based file system stored in a multi-protocol network file server, and network clients such as UNIX (Trademark) workstations may use the Network File System (NFS) protocol to access the shared disk based file system managed by the multi-protocol file server.
For enhanced data throughput, shared disk based file systems have been developed that permit network clients to share access to the file system by obtaining access permission and file metadata from a metadata server, and then using a high-speed data block access protocol to access the file data in one or more block storage devices. For example, as described in Vahalia, et al. U.S. Pat. No. 6,973,455 issued Dec. 6, 2005, incorporated herein by reference, a client is permitted to send data access commands directly to block storage of a network file server after obtaining a lock on at least a portion of the file and obtaining metadata indicating storage locations for the data in the block storage. For example, the client sends to the file server at least one request for access to a file. In response, the file server grants a lock to the client, and returns to the client metadata of the file including information specifying data storage locations in the block storage for storing data of the file. The client receives the metadata, and uses the metadata to produce at least one data access command for accessing the data storage locations in the block storage. The client sends the data access command to the block storage to read or write data to the file. For a write operation, the client may modify the metadata. When the client is finished writing to the file, the client returns modified metadata to the file server.
Shared disk based file systems are under development that permit a metadata server to grant extent-based range locks within a file to network clients. As described in David L. Black et al., “pNFS Block/Volume Layout,” NFSv4 Working Group Internet Draft, Mar. 4, 2007, parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. Layout extents returned to pNFS clients grant permission to read from or write to the extents. In general, the server will not be able to prevent a client which holds a layout for a file from accessing blocks of the physical disk not covered by the layout. In environments where the security requirements are such that client-side protection from access to storage outside the layout is not sufficient, pNFS block/volume layouts for pNFS should not be used.
Thus, shared disk based file systems that grant extent-based range locks to the clients and permit the clients to directly access the extents in a network block storage device raise security problems. There are two transports, the transport of the client access to the metadata server, and the transport of the client access to the network block storage device. Both of these transports should be secured, and have access controls implemented on them.
Most single host based file systems implicitly trust the host and the system administrator. The file system software running on the host is able to read and write to any block on the storage device that contains the file system, and the file system is responsible for implementing access controls. For most file systems this means that a super-user (root) can access any file in the file system. Users wishing to protect their data from root access must encrypt it, and ensure that even the super user does not have access to the encryption key.
Network based file systems introduce a new security model. In contrast to the single host file system, a network based file system defines two security domains. The first domain is the server domain, including the meta-data server in pNFS, the network block storage devices, and the server administrator, all of which are trusted. The second domain includes client machines and the client administrators, which are untrusted. As has been typical with NFS3 implementations, the file server administrator can explicitly configure the system such that a root user on a client host has no special privileges. This is often implemented by mapping the root user id (0) to a guest user id. No matter how the client machine is compromised, the file server still implements the access control and determines which data is accessible. Methods exist for securing the communications channel between the client and the file server, and systems like Kerberos can be used to strongly authenticate both the client identity and the user identity.
Shared SAN based file systems like MPFS and pNFS introduce new challenges in maintaining security. In these systems, untrusted hosts are granted read and write access to the storage devices used for the file system. As currently implemented using the standard SCSI-3 block command set (SBC-3), the storage device does not implement access control. In practice, LUN masking (storage groups), or other storage based mechanism are used to implement access control on a per logical unit basis, allowing only specific clients access to the storage. See, for example, Blumenau et al., U.S. Pat. No. 7,093,021 issued Aug. 15, 2006. Once a host is granted access to a logical unit, however, it can access any part of the logical unit. The host can read or write any block of the logical unit, and can possibly corrupt the file system. The assumption to date has been that the clients are in the same trust domain as the server. The assumption of clients being in the same trust domain as the server conflicts with the security model of NFS, and has caused problems such as malicious administrators writing to disks without having the proper rights granted, operator error, writing to disks using commands such as “dd”, aggressive disk management software, writing volume labels on all unlabeled disks, and reading from or writing to any range on a disk once gaining access to the disk.
There have been a number of approaches to dealing with the problem of securing client access to a block storage device after the client has been granted access by a file manager or metadata server.
The problem of securing client access to a network-attached storage device after the client has been granted access by a file manager has been discussed in Howard Gobioff et al., “Security for Network Attached Storage Devices,” Report CMU-CS-97-185, Oct. 23, 1997, School of Computer Science, Carnegie Mellon University, Pittsburgh, Pa. 15213. One approach to addressing this problem is called a grant-style approach, and another approach is called a capability approach.
In the grant-style approach, a client requests access from a file manager. The file manager grants client access and informs the network-attached storage device of the grant. The network-attached storage device acknowledges the grant. Once the network-attached storage device acknowledges the grant, the file manager provides the client with access information. The client then sends a request to the network-attached storage device, and receives a response.
In the capability approach, the client requests access from a file manager. The file manager responds by returning a “capability” to the client. The “capability” includes capability arguments and a capability key. The capability arguments contain a drive identifier, partition, object identifier, region (byte range), access rights, expiration time, minimum requirements, a basis key, and an audit identifier. The capability key is a cryptographic key used by a client to bind a specific storage device request to a capability through use of a machine identification code (MAC).
To address the problem of securing client access to a block storage device after the client has been granted access by a metadata server, EMC Corporation has used a host based filter driver (hrdp) which filters I/Os to block storage devices. Hrdp first scans all block storage devices looking to see if they have a label identifying an EMC Corp. “CELERRA” brand of storage device. If they do have such a label, a filter is installed which requires device open commands to pass a special flag. Any software that does not pass the special flag on open gets an error instead of a handle to the device. This solution solves some problems of operator error and aggressive disk management software, but still leaves the door open for incorrect install sequences and malicious system administrators. Such administrators can either remove the hrdp software, or can write their own programs and supply the special flag, thus gaining read/write access to the block storage devices.
An additional concern is a buggy host which does not respond to requests to return extents (layouts in pNFS) to the metadata server. In such a situation, either the host must fence itself from storage, which is unlikely since it has already refused to honor protocol requests, or the server must be capable of causing the storage to deny access of such a malfunctioning host.